工欲善其事，必先利其器！
但決定用什麼工具，用工具做什麼事情來解決什麼問題之前
看見全貌，理解流程與依賴關係，是最為重要的。
別盲目於很潮的新工具上，那只會留下債

站在未來，規劃現在

性能監測工具的介紹

在系統性能工程中，選擇合適的性能監測工具是關鍵，這不僅可以幫助我們發現潛在的性能瓶頸，還能為我們的優化工作提供數據支撐。以下是一些常用的性能監測工具，這些工具涵蓋了從應用程式層級到系統和網路層級的不同範疇。

1. pprof
pprof 是 Go 語言內建的性能分析工具，它可以幫助我們生成 CPU、記憶體、阻塞、Goroutine 等多種性能報告。pprof 可以直接與 Go 的 runtime 進行整合，並提供強大的性能視覺化能力，例如生成 Flamegraph 來展示程式在不同函數中的 CPU 時間分佈。

應用層級：pprof 主要用於分析應用程式的 CPU 使用、記憶體分配、Goroutine 使用情況等。

實際應用：當我們發現某個 Go 應用的性能出現問題時，使用 pprof 可以快速定位是哪部分代碼佔用了過多的 CPU 或記憶體。

後面會有更詳細的介紹。

2. Prometheus
Prometheus 是一個開源的系統監控和警報工具，主要用於收集和存儲時間序列數據。它與應用程式、伺服器主機、資料庫等進行整合，並透過 Pull 模式獲取各種性能指標數據。

是也能搭配 Push 模式或者 Prometheus remote-write。但都不如 Pull 來的適合。具體一些原因在連結中有提到，Pushgateway 其實會喪失每個監控對象的 up time指標，然後因為沒這個辨識能力，就也不會主動刪除推送給他的指標歷史資料。其次是它本身就是系統中的單點服務，可能會有單點失敗的問題。

系統層級：Prometheus 可以監控整個系統的資源使用情況，包括 CPU、記憶體、磁碟 I/O、網路流量等。

應用層級：它還能監控應用程式的運行情況，例如請求數、錯誤率、響應時間等。

實際應用：在一個分散式系統中，我們可以使用 Prometheus 來收集來自不同服務的性能數據，並且通過定義告警規則，在性能指標異常時及時發送警報。

圖片皆來自OpenTelemetry 入門指南︰建立全面可觀測性架構

3. Grafana
Grafana 是一個開源的數據可視化工具，它常與 Prometheus 搭配使用，用於展示和分析收集到的時間序列數據。Grafana 提供了豐富的圖表選項，可以將數據轉化為圖形化的展示，如折線圖、柱狀圖、熱圖等，幫助我們更直觀地理解系統性能狀況。

Grafana 其實主要精神是提供 Big Tent，即任何遙測資料都能統一在此工具上顯示跟分析。如果是採用 OpenTelemetry 產生的遙測資料，甚至能再 Grafana 中產生關聯，直接進行連結，這樣就能再同一個工具的瀏覽視窗內，連結至相關的遙測信號，查看其內容了。

系統層級：可以使用 Grafana 來可視化系統資源使用情況，並且展示趨勢和異常情況。

應用層級：Grafana 也常用來監控應用程式的各種性能指標，如響應時間、錯誤率、吞吐量等。

實際應用：在進行系統性能優化時，Grafana 可以幫助我們發現長期的性能趨勢，並為性能調整提供依據。

圖片來自OpenTelemetry 入門指南︰建立全面可觀測性架構

4. Flamegraph
Flamegraph 是一種視覺化工具，用於展示程式在不同函數或模塊中的 CPU 時間分佈。它通常與 pprof 等性能分析工具一起使用。Flamegraph的橫軸代表函數的執行順序，縱軸代表函數的堆疊深度，函數框的寬度表示該函數的 CPU 使用時間。

應用層級：主要用於分析應用程式的 CPU 使用情況，幫助開發者快速定位性能瓶頸。

實際應用：在進行程式碼性能調優時，通過生成火焰圖，我們可以直觀地看到哪些函數佔用了大量的 CPU 時間，從而針對性地進行優化。

5. OpenTelemetry
OpenTelemetry 是一個開源的可觀測性框架，用於收集、處理和導出應用程式的遙測信號，包括 traces（、metrics 和 logs。OpenTelemetry 可以幫助我們統一管理來自不同服務和工具的性能數據，從而更全面地了解系統的運行情況。還能自動的在每種遙測信號中注入共同的上下文資訊，方便我們如下圖那樣做關聯。能便於在分析時快速的將所有相關的信號都放在一起分析。這是以往的監控工具所作不到的。

在 OpenTelemetry 截至今日，框架的 Roadmap 已經有把 Profile 列入計畫中。雖然有其他工具可以提供 Profile 但會缺失了與其他遙測信號相互關聯的能力。

應用層級：OpenTelemetry 可以追蹤應用程式的請求路徑，從而了解不同操作的耗時情況和資源使用情況。

系統層級：通過 OpenTelemetry 收集的遙測數據，能夠整合到 Prometheus 或 Grafana 中，實現系統層級的監控和可視化。

實際應用：在一個微服務架構中，OpenTelemetry 可以追蹤跨服務的請求路徑，幫助我們分析和優化整體性能。此外，OpenTelemetry 的路線圖中提到了即將支持的分佈式 Profiling，這將進一步提升系統的觀測能力。此功能將允許用戶收集堆棧和 CPU 配置檔，並將其與分佈式追蹤和其他信號相關聯，從而能夠在分佈式系統中追蹤到具體的性能瓶頸並深入到代碼級別進行分析。這樣的改進使得 OpenTelemetry 成為一個能夠提供更全面可觀測性的工具，能夠真正滿足複雜系統的性能優化需求。

R.E.D. 指標與系統節點全覽圖

圖片皆來自OpenTelemetry 入門指南︰建立全面可觀測性架構

不同層級的性能監控

這些工具涵蓋了不同層級的性能監控：

應用程式層級：pprof、Flamegraph、OpenTelemetry
系統層級：Prometheus、Grafana、OpenTelemetry
網路層級：Prometheus 也可以用於監控網路流量與延遲，甚至憑證的監控都能作到

通過結合這些工具，我們能夠從多個角度全面掌握系統的性能狀況，並在發現性能問題時迅速作出反應，進行針對性的優化。這也是系統性能工程中必不可少的一環。

性能優化的最佳實踐與常見錯誤

在進行性能優化時，了解和遵循一些最佳實踐可以幫助我們更高效地解決問題，同時避免常見的陷阱。以下是一些在性能優化過程中應該注意的最佳實踐和常見錯誤。

最佳實踐

從測量開始
最佳實踐：在進行任何性能優化之前，首先要對系統的當前性能進行測量。使用如 pprof、Prometheus 等工具來收集基準數據，了解系統的瓶頸所在。優化後再次測量以驗證改進效果。

原因：沒有測量就無法確定問題所在，盲目優化可能會導致更嚴重的性能問題。透過測量，可以精確地定位性能瓶頸，並且提供實際數據來驗證優化是否有效。

資料做決策
最佳實踐：在優化過程中，應該依據收集到的性能數據來做決策，而不是憑直覺或假設。每一個優化步驟都應該有數據支持，並且能夠明確追蹤到性能的改進。

原因：數據驅動的決策能確保優化的有效性，避免浪費時間和資源在無效或低效的優化措施上。此外，數據也能幫助團隊識別其他潛在的問題區域，並進行相應的預防措施。

確保整體視角
最佳實踐：在優化系統性能時，應該從全局出發，考慮系統的所有組件和依賴關係，而不僅僅專注於單一部分。優化應用程式的同時，也要考慮網路、資料庫和其他系統資源。

原因：系統性能往往是由多個因素共同影響的，忽略任何一個部分都可能導致無法達成預期的優化效果。全局視角能幫助團隊識別跨組件的性能瓶頸，並制定更全面的優化策略。

了解流程做改動
最佳實踐：在進行任何改動之前，首先要充分了解整個系統的工作流程和依賴關係。這不僅包括應用層面的邏輯，還涉及網路拓撲、資料庫設計和資源分配等方面。

原因：對系統流程的深入理解有助於預測改動的影響，避免在優化一個部分時無意中引發其他部分的性能問題。改動應該是有計劃且有針對性的，並且要經過多次測試和驗證。

像是帳戶這功能幾乎在什麼軟體服務中都有，他的 API 只會有四個 是最基礎的 : 存款提款(扣款)批量/批次存款批量/批次扣款
其他再多的東西你可能會提， 譬如說 :

• 暫時凍結帳戶 ?
• 關閉帳戶 ?
• 刪除該帳戶 ?
  做很簡單， 都只是加個 flag 或者真的刪掉他就好， 但在你動手之前， 先問自己 : "我真的探詢過了我手上所有會來訪問我的系統的 app flow 了嗎 ? 寫下去會不會有後遺症"
  如果還沒盤點過流程，就輕易改動，很可能整體服務會產生不如你預期的行為導致不一致的發生。

DDD 的工作坊與很多軟體開發方法，其實都是在鼓勵掌握全局視角，了解流程與依賴關係。
方便做出精準沒有過多風險的決策。

常見錯誤

在性能優化的過程中，開發者可能會犯一些常見的錯誤，這些錯誤可能會導致優化效果不佳，甚至引發新的問題。了解這些常見錯誤可以幫助避免陷入性能優化的陷阱。

1. 過度優化
錯誤描述：過度優化是指在沒有明確性能瓶頸或業務需求的情況下，投入過多時間和資源進行性能優化。

結果：過度優化往往會導致開發時間的浪費，並且可能引入不必要的代碼複雜性，降低系統的可維護性和穩定性。此外，過度優化可能會忽視其他更為重要的功能開發或維護工作。

2. 忽視測量與驗證
錯誤描述：在進行優化之前或之後，沒有進行充分的性能測量與驗證，僅依賴直覺或假設進行優化。

結果：這種做法往往導致無效的優化，甚至可能引發新的性能問題。沒有測量就無法確定優化的實際效果，可能會錯過真正的性能瓶頸，甚至可能導致性能的下降。

3. 只關注單一指標
錯誤描述：在優化過程中，過於關注某一個性能指標（例如 CPU 使用率或回應時間），而忽視了其他可能同樣重要的指標（如記憶體使用、I/O 性能、網路延遲等）。

結果：這樣的優化可能會造成其他部分的性能惡化。例如，過度優化 CPU 使用率可能會增加記憶體使用或 I/O 負荷，導致整體系統性能反而下降。

4. 忽略全局視角
錯誤描述：在優化時僅關注某一部分系統（如應用程式層），而忽視了整個系統的其他組件和依賴關係（如資料庫、網路、外部服務等）。

結果：這種局限性的優化往往無法解決系統的整體性能問題，甚至可能導致新的瓶頸出現。例如，優化了應用層的處理速度，但忽略了資料庫查詢性能，最終導致性能瓶頸轉移到資料庫層。

5. 忽視性能回歸測試
錯誤描述：在優化過程中，沒有進行充分的回歸測試，未能檢查優化後的系統是否引入了新的性能問題或缺陷。

結果：性能回歸測試能確保在優化過程中沒有引入新的問題。忽視這一步驟可能導致系統出現不可預測的問題，降低整體穩定性，並可能在後期運行中產生難以發現和解決的性能問題。

小結

在系統性能工程中，選擇適當的監測工具是優化過程的基礎。從 pprof 到 OpenTelemetry，這些工具涵蓋了應用程式、系統和網路層級的監控，為我們提供了全面的數據支持。在進行性能優化時，遵循測量先行、數據驅動決策和全局視角等最佳實踐，可以幫助我們更精確地識別和解決性能瓶頸。然而，開發者也需要警惕常見的錯誤，如過度優化、忽視測量和驗證、過於集中於單一指標、忽略全局視角，以及缺乏性能回歸測試。通過了解並避免這些錯誤，我們能夠確保優化工作的有效性和系統的穩定性，最終達成提升性能的目標。